Transaction management system and program for configuring online shopping system

ABSTRACT

A transaction management system for configurating an on-line shopping system. The on-line shopping system including the transaction management system also includes an IPS-RADIUS server, an account management system operated by a carrier, and an article supplier server. The transaction management system has contract DB storing plural sets of contract information each having a user ID, a customer code, an ISP code, an accounted party code specifying carrier (or account management system), and so on. When a customer buys an article by accessing to an article supplier server, the server transmits an accounting process request containing a customer code to the transaction management system. The transaction management system, when receiving the accounting process request, attempts to authenticate the identity of the customer. If the customer is authenticated, the transaction management system functions so that the carrier collects a fee of the bought article together with a fee charged for the service provided by the carrier.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of application Ser. No. 10/864,171,filed May 21, 2001, allowed.

This application is based upon and claims the priority of Japaneseapplication no. 2001-157179, filed May 26, 2000, and U.S. patentapplication Ser. No. 10/864,171, filed May 21, 2001, the contents ofwhich being incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a transaction management system forconfiguring an online shopping system and to a program used for acomputer to function as a system for configuring the online shoppingsystem.

2. Description of the Related Art

As broadly known, a variety of articles of trade have been sold throughthe Internet over the recent years. When purchasing an article, aspecific process must be executed for paying a price of the article.Procedure of the process is different depending on an article supplier(dealer), however, the procedure can be roughly classified into aprocedure requiring an input of a credit card number and a procedurerequiring an input of unique pieces of information (such as a membershipnumber, a password etc.) given to a user (member).

With an advancement of an SSL (Secure Sockets Layer) technology, thoughthere decreases a possibility in which the credit card number inputtedto a self-terminal leaks out (wiretapping) during a period till thecredit card number arrives at a server of the article supplier, aproblem arises, wherein the credit card number might be adversely usedafter arriving at the server. Therefore, on the occasion of purchasingthe article dealt on the Internet, some users prefer not a payment bythe credit card but a money transfer at a bank, a cash on delivery andso on, though the procedure becomes troublesome.

In the case of buying the article by inputting the membership number andthe password, there does not arise the problem that the credit cardnumber leaks out (this problem might, however, occur when obtaining themembership). The articles that can be purchased by inputting a couple ofa certain membership number and a certain password are limited to thoseprovided by the article supplier who gave this membership number.Therefore, in the case of obtaining various types of articles on theInternet, pieces of information on a multiplicity of members areobtained and must be managed so as not to be known by others. Further,in the case of purchasing the articles by use of those membershipnumbers, a problem is that a payment of each article must be doneaccording to the membership number used.

Moreover, everybody can buy the articles on the Internet on a simplecondition that he or she knows special pieces of information (the creditcard number, the membership number etc.), so that there recently arisesa problem that the infants get harmful articles on the Internet.

Under such circumstances, it is a primary object of the presentinvention to provide a transaction management system capable ofconfiguring an online shopping system in which the user purchase thearticle without inputting the credit card number, and a necessity ofmanaging new items of information for utilizing the system does notoccur.

It is another object of the present invention to provide a transactionmanagement system capable of configuring an online shopping systemcapable of restricting the articles that the users are allowed topurchase.

It is a further object of the present invention to provide a programexecuted by a computer to function as a system corresponding to eachtransaction management system.

SUMMARY OF THE INVENTION

To accomplish the above objects, according to one aspect of the presentinvention, a transaction management system comprises an authenticationpart for performing authentication by sending a user identifier and apassword to an authentication system operated by an Internet serviceprovider that should authenticate an accounting target user, and arequest part for making an accounting request to an accountingprocessing system operated by other than the Internet service providerwhen the authentication part succeeds in the authentication.

With this transaction management system used, it is feasible toconfigure an online shopping system capable of purchasing an article oftrade with the existing information (a user identifier and a password)and making one single accounting process system execute a settlement ofsome transactions.

For actualizing the transaction management system according to thepresent invention, the accounting process system may be operated by atype 1 carrier for collecting fees from a plurality of contractors.There may be selected the accounting process system that retains aunique piece of contractor identifier given to each of the plurality ofcontractors and state-of-contract information showing whether or not thecontractor has a nonpayment of the fee. The transaction managementsystem may further comprise a mapping-of-information storage part forstoring a mapping of each of the plurality of user identifiers to atleast one contractor identifier, an acquisition part for acquiringthrough communications the user identifier and the password given to auser by the Internet service provider from the user ordering a purchaseof a certain article to any one of one or more purchase order acceptsystem for accepting the order of purchasing the article through thecommunications, and the contractor identifier of the contractor made topay a fee related to the article, and a judgement part for judging basedon the state-of-contract information retained corresponding to thecontractor identifier acquired by the acquisition part whether or notthe contractor identified by the contractor identifier has thenonpayment of fee by exchanging information with the accounting processsystem. The authentication part may authenticate a user's identity onthe basis of the user identifier and the password acquired by theacquisition part by exchanging information through communications withthe authentication system if the user identifier and the contractoridentifier acquired by the acquisition have their mapping given by themapping information stored in the mapping-of-information storage part.The request part may request the type 1 carrier to collect a price ofthe article from the contractor identified by the contractor identifierby notifying, when the user identity is authenticated by theauthentication part and when the judgment part judges that thecontractor does not have any nonpayment of fee, the purchase orderaccept system accepting the purchase order from the user that the user'sidentity has been authenticated, and by notifying the accounting processsystem of the contractor identifier acquired by the acquisition part andof a price of the article ordered for its purchase.

Namely, the order accept system operated by the article supplier thatconducts online dealing in linkage with the transaction managementsystem of the present invention, does not authenticate by itself anidentity of the orderer and request the transaction management system toauthenticate the identity of the orderer. Note that this request may begiven to the transaction management system either from the order acceptsystem or from a computer terminal of the orderer.

The transaction management system recognizing that an order ofpurchasing a certain article of trade is issued to the purchase orderaccept system, acquires from the orderer through communications the useridentifier and the password given to the orderer by an Internet serviceprovider, and a contractor identifier of the contractor made to pay thefee related to the article concerned. That is, the transactionmanagement system acquires these pieces of information not through thepurchase order accept system but directly from the orderer.

Then, the transaction management system (the authentication part)accesses the accounting processing system and thereby judges whether thecontractor (made corresponding to the orderer through the mapping ofinformation) specified by the orderer, has a nonpayment of fee or not.

Further, the transaction management system (the request part) requeststhe authentication system operated by an ISP to authenticate thecontractor's identity by use of the user identifier and the passwordacquired from the orderer. Then, the transaction management system (therequest part), when the authentication system authenticate the identityand when judging that the contractor does not have any nonpayment offee, notifies the purchase order accept system that the identity hasbeen authenticated, and notifies the accounting process system of thecontractor identifier and a price of the article. The accounting processsystem receiving this notification treats this notification as arequest, made by the contractor identified by the notified contractoridentifier, for collecting the (notified) price of the article, and anecessary process is executed.

Namely, according to the online shopping system utilizing thistransaction management system, the orderer is able to purchase thearticle (including a contract for utilizing a service charged a fee)simply by inputting the information (the user identifier, the password)given from the ISP and the information (the contractor identifier) givenfrom the type 1 carrier. That is to say, the orderer can purchase thearticle without inputting the credit card number. Further, it followsthat the orderer can buy the article without managing a new item ofinformation for utilizing (purchasing the article) the system. Moreover,a claim for payment of a purchase fee of the article is given from thetype 1 carrier, and therefore the orderer is able to simultaneously makethe payment to the type 1 carrier and the payment of the price of thearticle purchased. Furthermore, in the case of using the presenttransaction management system, it is confirmed that the contractor doesnot have any nonpayment of fee, and hence it is possible to configurethe system with a low probability of occurrence of a transaction inwhich the fee of the article can not be collected.

For actualizing the transaction management system of the presentinvention in such a form as to aim at the accounting process systemoperated by the type 1 carrier, there may be selected the accountingprocess system that retains a unique piece of contractor identifiergiven to each of the plurality of contractors, a piece ofstate-of-contract information indicating whether or not the contractorhas the nonpayment of fee, and plural pieces of attribute informationfor defining each of attributes of a plurality of categories withrespect to the contractor. The acquisition part may acquire from theuser pieces of information on the attributes of which the numbercorresponds to a price of the article ordered to be purchased, theseattributes being selected at random from the attributes of the pluralityof categories. The transaction management system may further comprise ajudgement part for judging by exchanging the information with theaccounting process system whether or not the information on theattributes of which the number corresponds to the price of the articlethat has been acquired by the acquisition part, is coincident with theattribute information on the same attributes that has been retained inthe accounting process system. The request part may function when thejudgement part judges that the information on the attributes of whichthe number corresponds to the price of the article that has beenacquired by the acquisition part, is coincident with the attributeinformation on the same attributes that has been retained in theaccounting process system.

Namely, the transaction management system may be constructed toauthenticate the identity by making use of other items of information(an address, a telephone number etc. of the contractor) managedoriginally in the accounting process system operated by the type 1carrier. If the transaction management system is thus constructed, it isfeasible to configure the system with a less probability that the fee ofthe article can not be collected because of a mistake in authenticationof the identity.

Further, the transaction management system of the present invention mayfurther comprise a purchase condition information storage part storedwith mappings of one or more pieces of purchase condition informationfor defining an attribute of the article to user identifiers differentfrom each other, a judgement part for judging whether or not there issatisfied a purchase non-permission condition that the purchasecondition information corresponding to the user identifier acquired bythe acquisition part be stored in the purchase condition informationstorage part, and that the article ordered to be purchased does not haveany attribute defined by the purchase condition information. The requestpart may function only when the judging part judges that the purchasenon-permission condition is not satisfied.

With the thus constructed transaction management system used, it ispossible to configure the online shopping system capable of restrictingthe article per orderer in terms of its attributes (category and anamount of money), which can be bought by this orderer.

In the case of constructing the transaction management system asdescribed above, this transaction management system may further comprisea second password storage part stored with one or more second passwordscorresponding respectively to one or more pieces of purchase conditioninformation stored in the purchase condition information storage part,and a purchase condition information changing part for changing, whenthe same information as any one of the second passwords stored in thesecond password storage part, the purchase condition informationcorresponding to this second password into a piece of informationcorresponding to information that will be inputted thereafter.

If the transaction management system is thus constructed, it is feasibleto configure the online shopping system in which the contractor (e.g., aparent of the orderer) is able to restrict the article in terms of theattributes (category and an amount of money), which can be bought bythis orderer.

Further, the transaction management system of the present invention mayfurther comprise a second name acquisition part for causing a computerterminal used by the user to display a name of the article ordered to bepurchased and acquiring a second name used as a substitute for the nameof the article from the user through the computer terminal. The requestpart, if notifying the purchase order accept system that the identityhas been authenticated and when the second name has been acquired by thesecond name acquisition part, may notify the accounting process systemof the second name together with the price, and may notify, when thesecond name has not been acquired by the second name acquisition part,the accounting process system of the name of the processing targetarticle together with the price.

The online shopping system in which the orderer can specify the nameshown in the bill can be configured by use of the thus constructedtransaction management system and the accounting process system thatcreates a bill in which the information of which the request partnotifies is used as a account item name, for the processing targetarticle, of a bill for a contractor identified by the contractoridentifier acquired by the acquisition part.

Moreover, in the transaction management system according to the presentinvention, the authentication system may be a system that retains amapping of an e-mail address of each contract user to a user identifierof the same contract user. The transaction management system may furthercomprise a mail delivery part for delivering, if the request partnotifies the purchase order accept system that the identity has beenauthenticated, an e-mail showing that the article has been purchased,with the e-mail address being used as a destination address, which isretained corresponding to the user identifier acquired by theacquisition part in the authentication system.

With the transaction management system thus constructed, when purchasingthe article, the e-mail is delivered to the user having the user ID usedfor this purchase, and hence there can be obtained the system in whichif the user ID, the password etc. leak out and are adversely used, theuser himself or herself can immediately recognize this leakage.

According to another aspect of the present invention, a transactionmanagement system for requesting a plurality of accounting processsystems to execute accounting processes of fees, comprises a part forreceiving a process request for an accounting request from a customer asa payer of fee, an acquisition part for acquiring identifyinginformation of the accounting process system that is utilized by the feepayer on the basis of the process request received, and necessary itemsof information for authentication, and a part for requesting theaccounting process system concerned to execute the accounting process ofthe fee on the basis of the information acquired by the acquisitionpart.

The online shopping system capable of selecting the accounting processsystem as a fee payee by using this transaction management system.

A program is structured so that a computer executes this program,thereby functioning as a system substantially equal to the transactionmanagement system of the present invention. Accordingly, if using asystem in which the program according to the present invention isinstalled into the computer, the online shopping system exhibiting theeffects described above can be configured.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects and advantages of the present invention willbecome clear from the following description with reference to theaccompanying drawings, wherein:

FIG. 1 is a diagram showing architecture of an online shopping systemusing a transaction management system in one embodiment of the presentinvention;

FIG. 2 is an explanatory diagram showing a user database provided in anISP-RADIUS server connected to the transaction management system in theembodiment;

FIG. 3 is an explanatory diagram showing a customer database provided ina account management system connected to the transaction managementsystem in the embodiment;

FIG. 4 is an explanatory diagram showing an article management databaseprovided in a transaction management system connected to the transactionmanagement system in the embodiment;

FIG. 5 is an explanatory diagram showing an article classification addeditem count database provided in the transaction management system;

FIG. 6 is an explanatory diagram showing a price zone added item countdatabase provided in the transaction management system;

FIG. 7 is an explanatory diagram showing an added item count databaseprovided in the transaction management system;

FIG. 8 is an explanatory diagram showing a contract database provided inthe transaction management system;

FIG. 9 is an explanatory diagram showing a contract procedure ofutilizing a settlement service provided by the online shopping system;

FIG. 10 is an explanatory diagram showing a purchase restraint conditiondatabase provided in the transaction management system;

FIG. 11 is an explanatory flowchart showing a function of updating thepurchase restraint condition database provided in the transactionmanagement system;

FIGS. 12A, 12B and 12C are explanatory diagrams each showing a Web pageprovided by an article supplier server connected to the transactionmanagement system;

FIG. 13 is a flowchart showing a process started when the transactionmanagement system receives an accounting process request;

FIG. 14 is a flowchart continued from FIG. 13, showing the processstarted when the transaction management system receives the accountingprocess request;

FIG. 15 is a flowchart continued from FIG. 14, showing the processstarted when the transaction management system receives the accountingprocess request;

FIGS. 16˜21 are explanatory diagrams each showing a Web page provided bythe transaction management system to a computer terminal;

FIG. 22 is an explanatory diagram showing an accounting databaseprovided in the transaction management system;

FIG. 23 is an explanatory diagram showing a function of the accountmanagement system connected to the transaction management system; and

FIG. 24 is an explanatory diagram showing a bill created by the accountmanagement system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention will hereinafter be described withreference to the accompanying drawings.

FIG. 1 shows architecture of an online shopping system using atransaction management system in one embodiment of the presentinvention. As shown in FIG. 1, the present online shopping system isconfigured by one or more computer terminals 110, one or more articlesupplier servers 120, one or more ISP-RADIUS servers 130, one or moreaccount management systems 140, and a transaction management system 10connected to these apparatuses via leased lines or the Internet 100.

The ISP-RADIUS (Remote Authentication Dial-in User Service) server 130is defined as a server operated by an ISP (Internet Service Provider)for providing Internet connection services based on a dial-up IPconnection. The ISP-RADIUS server 130 includes a user database (user DB)131 stored with, as schematically shown in FIG. 2, a user ID, apassword, an e-mail address, etc. of each user having established acontract for utilizing the service. Further, the ISP-RADIUS server 130incorporates a function of answering a variety of inquiries given fromthe transaction management system 10.

The article supplier server 120 is defined as a Web server for providingWeb pages for dealing the article, and is operated by an articlesupplier. The article supplier server 120 configuring the present onlineshopping system is, though a detailed discussion will be given later on,structured to transmit, when receiving an order of the article of trade,to the transaction management system 10 an IP address of the computerterminal 110 used by a person who has issued this order and anaccounting process request containing an article code, etc. of thearticle concerned.

The account management system 140 is a system operated by a type 1carrier (which will hereinafter simply called a carrier). The accountmanagement system 140 has a function of issuing bills for collectingfees charged for utilizing the communication services provided by thecarrier from respective customers. The account management system 140includes a customer database 141 stored with customer informationconsisting of, as schematically shown in FIG. 3, customer codes, piecesof information showing contract conditions (a state of the contract, astate of nonpayment) and various items of customer information (zipcodes, names of the administrative divisions of Japan, and so on) of therespective customers having established the contracts with the carrier.

The basic operation of the account management system 140 configuring thepresent online shopping system is the same as that of the generalaccount management system. The account management system 140 is,however, given a function of answering a variety of inquiries from thetransaction management system 10. The account management system 140 isfurther given a function of reflecting a content of the accountinginformation containing the customer code in a content of the bill to thecustomer given this customer code.

The transaction management system 10 is a system actualized byinstalling a program developed for the present online shopping systeminto a computer. The transaction management system 10, when receivingthe accounting process request transmitted by the article supplierserver 120 after receiving the order of the article, obtains somecategories of information for authenticating an identity of the personwho has issued this order. Subsequently, the transaction managementsystem 10 exchanges pieces of information with the ISP-RADIUS server 130relative to the ISP with whom the orderer made the contract, and withthe account management system 140 relative to the carrier with whom theorderer or a parent thereof made the contract, thereby attempting toauthenticate the identity of the orderer on the basis of the informationobtained. Then, if the identity of the orderer is authenticated, thetransaction management system 10 functions so that the carrier with whomthe orderer (or the parent thereof) made the contract collects fees ofordered articles together with a fee charged for the service provided bythe carrier concerned. Further, the transaction management system 10 isstructured to make the account management system 140 to issue a bill, inwhich not a name peculiar to the article but a name given by the ordereris written, as the item name of the ordered article.

For enabling this type of service (which will hereinafter be called asettlement service) to be provided, the transaction management system 10is provided with an article management database 21, an articleclassification added item count database 22, a price zone added itemcount database 23, an added item database 24, a contract database 25, apurchase restraint condition database 26 and an accounting database 27.

When receiving the accounting process request, the transactionmanagement system 10 functions with reference to six pieces of databases21˜26 excluding the accounting database 27. Therefore, before launchinginto a discussion on the essential function of the transactionmanagement system 10, the databases 21˜26 are to be described.

The article management database 21 provided in the transactionmanagement system 10 is a database stored with, as shown in FIG. 4,plural sets of article management information consisting of an articlecode, an article standard name, a minimum price, a maximum price, anarticle classification, an article supplier code and a returndestination address.

The article code of the article management information is a piece ofarticle identifying information used for managing the article. Thearticle standard name is an article name given by the article supplier(or a manufacturer of the article). The minimum price and the maximumprice are pieces of information for defining a price range of thearticle of which a price might fluctuate. In the article managementinformation on a normal article (with no fluctuation of its price), bothof the minimum and maximum prices thereof may be considered coincidentwith a sales price of this article. The article classification is apiece of information used as an index for restricting purchasers of thearticle. The article supplier code is a piece of identifying informationgiven to the article supplier dealing the article. The returndestination address is defined as an IP address of the article supplierserver 120 operated by the article supplier concerned.

The contents (data) in the article management database 21 are updated toretain the article management information on all the articles that aredealt by use of the transaction management system 10. Namely, when acontract agreed upon between a new article supplier and an administrator(that will be hereinafter termed a settler) of the transactionmanagement system 10 about making a settlement using the presenttransaction management system 10, and when it is agreed upon that thearticle supplier having already established the contract sells a newarticle, a new item of article information is added to the articlemanagement database 21. Further, if a price of a certain article ischanged under the minimum price or above the maximum price set aboutthis article, the minimum or maximum price is changed.

The article classification added item count database 22 is a databasestored with, as schematically shown in FIG. 5, an article classificationadded item count defined as numeric value information on each of thearticle classifications. Moreover, the price zone added item countdatabase 23 is a database stored with, as schematically shown in FIG. 6,an price zone added item count with respect to an article price zone (arange defined by a lower limit price and an upper limit price). Thoughpurposes of these added item counts will be mentioned later on, in thearticle classification added item count database 22, the articleclassification added item count is set for each of the articleclassifications so that a breadth of the range of the purchasers of thearticle coming under the corresponding article classification and thearticle classification add item count exhibit a negative correlation.Further, each price zone added item count is set in the price zone addeditem count database 23 so that the price zone added item countcorresponding to the price zone becomes larger as the price zoneincreases as shown in FIG. 6.

The added item database 24 is a database stored with, as schematicallyshown in FIG. 7, plural pieces of item specifying information (“zipcode”, “zip code 3-2”, etc.) corresponding to a plurality of accountedparty codes. The item specifying information, corresponding to a certainaccounted party code, stored in the added item database 24 is an itemname itself (“zip code”) of the information stored in the customer DB141 in the account management system 140 that is identified by theaccounted party code, or a piece of information (“zip code 3-2”)containing two pieces of hyphenated numerical values subsequent to theitem name. An application of the item specifying information will beexplained later on. Note that the information is added to this addeditem database 24 when a contract is agreed upon between a new carrierand the settler about making a settlement using the transactionmanagement system 10.

The contract database 25 is a database capable of, as shown in FIG. 8,storing plural sets of contract information each consisting of a userID, a customer code, an ISP code, an accounted party code, and apurchase restraint condition setting password. The ISP code is definedas a piece of information given to the ISP and the ISP-RADIUS server130.

Contract information is added to this contract database 25 when aservice contract is established between an applicant for utilizing asettlement service and a settler.

To be specific, as schematically shown in FIG. 9, the applicant forutilizing this settlement service, to start with, submits to the settleran application form 30 for utilizing the service, in which an ISP name,a user ID, a carrier name, a customer code etc. are written.

The ISP name and the user ID that should be written in this applicationform 30 are related to the ISP with whom the service utilizing applicantmakes the contract. The carrier name and the customer code are relatedto the carrier with whom the service utilizing applicant or a parentthereof (the head of a household) makes the contract. Note that if theservice utilizing applicant (or the parent thereof) makes the contractwith a plurality of carriers, the service utilizing applicant may makean application for utilizing the settlement service by writing thecarrier names of two or more carriers and the customer codes.

The settler receiving a submission of this application form 30 inquiresof the ISP identified by the ISP name written in the application formand of each carrier identified by the carrier name written in theapplication form for confirmation as to whether contents written in theapplication form 30 are correct (step S101).

Namely, the settler inquires of the ISP for confirming an existence ofthe contractor given the user ID written in the application form 30.Further, the settler inquires of the carrier for confirming an existenceof the contractor given the customer code written in the applicationform 30. Note that the inquiry of the carrier is made, if the contractorgiven the above customer code exists, in the form of requesting thecarrier to notify of a name, an address, etc. of the contractor with thesame customer code.

If unable to confirm that the contents written in application form arecorrect, namely, if a negative answer to the inquiry is given from theISP or the carrier (step S102; NO), the settler notifies the contractapplicant of being unable to make a contract (step S110), and finishesthe process for the application form 30 received.

Whereas if able to confirm that the contents written in the applicationform 30 are correct (step S102; YES), the settler sends to the payer adocument for having a content of the application of the contractapplicant confirmed (step S103).

Then, if an approval of the payer is obtained (step S104; YES), thecontractor determines a purchase restraint condition setting password(step S105), and adds to the contract database 25 pieces of contractinformation consisting of the purchase restraint condition settingpassword and information corresponding to the information written in theapplication form 30 (step S106). If a plurality of carriers arespecified in the application form 30, the settler adds to the contractdatabase 25 plural items of contract information in which values set asthe user ID, the ISP code and the restraint condition setting passwordare identical.

Thereafter, the contractor notifies the payer of the purchase restraintcondition setting password (step S107), and also notifies the serviceutilizing applicant that the settlement service become utilizable (stepS108), thereby finishing the process for the application form 30.

The purchase restraint condition database 26 is a database for, as shownin FIG. 10, storing mappings, to the user ID, of a purchase upper limitamount for indicating an upper limit of the price of the article towhich the user given this user ID is able to purchase and of information(shown in the form of X/o in FIG. 10) for indicating whether the orderof the article in each article classification which is issued the usergiven the same user ID is rejected or not.

The transaction management system 10, based on an indication given fromthe payer with the purchase restraint condition setting password whichthe system 10 has been notified of, registers purchase restraintcondition information (consisting of the user ID and a set ofinformation corresponding thereto) in the purchase restraint conditiondatabase 26, or changes the purchase restraint condition informationwithin the purchase restraint condition database 26.

More specifically, the transaction management system 10 incorporates afunction that works in steps shown in FIG. 11. Namely, when receiving apredetermined HTTP (Hypertext Transfer Protocol) request, thetransaction management system 10 provides the computer terminal 110issuing this request with a Web page including input boxes for inputtingthe user ID and the purchase restraint condition setting PW and atransmission button for transmitting the information inputted in theseinput boxes to the transaction management system 10 (step S201). Ifreceiving information transmitted as a result of an event that thetransmission button on the Web page is pressed (step S202; YES), thetransaction management system 10 searches from the contract database 25the contract information in which the received user ID and purchaserestraint condition setting PW are set (step S203).

If the search hits the contract information described above (step S204:YES), the transaction management system 10 provides the computerterminal 110 with a purchase restraint condition setting Web pageincluding input boxes for inputting elements excluding the user ID ofthe purchase restraint condition information and a transmission buttonfor transmitting information inputted to the input boxes to thetransaction management system 10, and updates contents in the purchaserestraint condition database 26 in accordance with the informationtransmitted by pressing the transmission button (step S205). Note thatthe transaction management system 10, if the purchase constraintcondition information containing the user ID received in step S202 isstored the purchase restraint condition database 26 in step S205,provides the computer terminal 110 with the purchase restraint conditionsetting Web page on which initial values corresponding to the purchaserestraint condition information are displayed in the input boxes. Then,the transaction management system 10 rewrites corresponding pieces ofpurchase restraint condition information in the purchase restraintcondition database 26 in accordance with the information inputted to theWeb page. Whereas if the purchase restraint condition informationcontaining the user ID received is not stored in purchase restraintcondition database 26, the transaction management system 10 provides thecomputer terminal 110 with the purchase restraint condition setting Webpage in which the default values are displayed in the input boxes. Then,the transaction management system 10 adds to the purchase restraintcondition database 26 the purchase restraint condition informationconsisting of the information inputted to the Web page and the user IDreceived.

Further, if the contract information containing the user ID received andthe purchase restraint condition setting PW is not searched from thecontract database 25 (step S204; NO), the transaction management system10 provides the computer terminal 110 with a Web page showing that thepurchase restraint condition can not be set (step S206), and finishesthe processing.

A function of the present online shopping system when an order of thearticle is received, will hereinafter be described.

The article supplier server 120 used in the present online shoppingsystem, when receiving the order of the article, is structured totransmit a settlement request containing an IP address, an article code,a sales price and a accounted party code to the transaction managementsystem 10.

To be more specific, the article supplier server 120 is, correspondingto an event by the orderer, structured to sequentially display, forinstance, Web pages as shown in FIGS. 12A, 12B and 12C on the display ofthe computer terminal 110. The article supplier server 120, whendetecting an event that a “YES” button on the Web page shown in FIG. 12C(when receiving a request sent from the computer terminal 110 upondepressing the “YES” button), transmits a settlement request containingthe IP address of the computer terminal 110, the article code of thearticle selected by the orderer, the sales price of the article and theaccounted party code representing a carrier selected by the user.

The transaction management system 10 receiving this settlement requestfunctions in steps shown in FIGS. 13 through 15.

That is, as shown in FIG. 13, the transaction management system 10, tobegin with, searches from the article management DB 21 a piece ofarticle management information in which the article code is coincidentwith an article code contained in the accounting process request (whichwill hereinafter be referred to as a processing target article code)(step S301).

If the search does not hit the article management information describedabove (step S302; NO), the transaction management system 10 sends animpossible-of-settlement notifying page data, wherein the IP addresscontained in the accounting process request (which will hereinafter becalled an orderer IP address) is used as a destination address (stepS304). Herein, the impossible-of-settlement page data may be defined asdata for the computer terminal 110 (a Web browser) having received thesame data to display a Web page indicating a message that the settlementcan not be made. Then, the transaction management system 10 finishes theprocessing for the accounting process request received.

On the other hand, if the search hits the article management informationcontaining the same article code as the processing target article code(step S302; YES), the transaction management system 10 judges whether ornot a processing target sales price (contained in the accounting processrequest) falls within a specified price range defined by the minimumprice and the maximum price (step S303). Then, if the processing targetsales price does not fall within the specified price range (step S303;NO), the processing comes to an end after sending theimpossible-of-settlement notifying page data in step S304. Note that theprocessing branches to “NO” in steps S302 and S303 in a case where somesort of trouble occurs in the system such as registering the articlemanagement DB 21 with the article management information containingerroneous contents and dealing an article with no registration of itsarticle management information.

If the processing target sales price falls within the specified pricerange (step S303; YES), the transaction management system 10 reads anarticle classification added item count corresponding to the articleclassification contained in the processing target article managementinformation from the article classification added item count DB 22 (stepS305). Subsequently, the transaction management system 10 reads a pricezone added item count corresponding to the processing target sales pricefrom the price zone added item count DB 23 (step S306), and calculates asum of these two counts as an authentication added item count (stepS307).

If the calculated authentication added item count is “0” (step S308;YES), the transaction management system 10, with the orderer IP addressused as a destination address, transmits an identity authentication pagedata used for the Web browser to display an identity authentication pagecontaining the input boxes for inputting the user ID, the password andthe customer code, and the transmission button (step S309).

Whereas if the calculated authentication added item count is not “0”(step S308; NO), the transaction management system 10 selects at randomone or more pieces of item specifying information, the number of whichcoincides with the authentication added item count, from pieces of itemspecifying information stored as a mapping to the accounted party codein the processing target article management information in the addeditem DB 24 (step S310). Subsequently, the transaction management system10, with the orderer IP address used as a destination address, transmitsthe identity authentication page data used for the Web browser todisplay an identity authentication page having an added input box forinputting a piece of information specified by each of the selectedpieces of item specifying information (step S311).

Namely, the transaction management system 10, if the calculatedauthentication added item count is, e.g., “2”, transmits such anidentity authentication page data that the identity authentication pageas shown in FIG. 16 is displayed on the display of the computer terminal110 on which the Web page as shown in FIG. 12C has been displayed. Notethat if the item specifying information selected in step S310 is “zipcode 3-2”, in step S311, the transaction management system 10 createsand transmits such an data that an identity authentication page havingan addition of an input box for inputting a numeric value for 3 through2 digits of the zip code comes to be displayed.

In the case of receiving the orderer input information transmitted bypressing the transmission button on the identity authentication page andcontaining the information inputted to the input boxes (FIG. 14: stepS320; YES), the transaction management system 10 judges from thecontents of the orderer input information whether or not the ordererinputs all pieces of information (step S321). If there is theinformation that is not inputted (step S321; NO), the transactionmanagement system 10 transmits the data for displaying a Web page forprompting the orderer to input the information that is not yet inputtedto the computer terminal 110 having transmitted the orderer inputinformation (which will hereinafter be called an orderer terminal) (stepS322). Namely, the transaction management system 10 transmits in stepS322 such an item of data that the Web page as shown in FIG. 17 isdisplayed on the orderer terminal.

Thereafter, the transaction management system 10 returns to step S320and, when receiving the orderer input information, starts the processingfrom step S321 (more precisely, the transaction management system 10waits in an unillustrated step for receiving various pieces ofinformation (HTTP request) containing the orderer input information,and, when the received information is the orderer input information,starts the process from step S321).

If all pieces of information are inputted (step S321; YES), thetransaction management system 10 searches from the contract DB 25 thecontract information containing the user ID and the customer codeinputted by the orderer (step S323). If the search does not hit thecontract information described above (step S324; NO), the transactionmanagement system 10 transmits to the orderer terminal input mistakenotifying page data for the browser to display a Web page showing thatan erroneous piece of information is inputted (step S325).

If the contract information containing the user ID and the customer codeinputted by the orderer can be searched from the contract DB 25 (stepS324; YES), the transaction management system 10 executes a process forconfirming that the user ID, the password and the customer code inputtedby the orderer are correct with reference to the contract informationsearched (step S326). To be specific, the transaction management system10 inquires of the ISP-RADIUS server 130 corresponding to the ISP codecontained in the searched contract information about whether or not theuser ID, the password inputted by the orderer are related to the user asa contractor. At the same time, the transaction management system 10inquires of the account management system 140 corresponding to theaccounted party code contained in the searched contract informationabout whether or not the customer code inputted by the orderer isrelated to the customer as a contractor. Further, when the ordererproves to be a contractor of the account management system 140, thetransaction management system 10 inquires about whether or not theorderer concerned has a nonpayment of fee and so on.

Then, if any one of or neither validity of the user ID and the passwordinputted by the orderer nor validity of the customer code can beconfirmed (step S327; NO), the transaction management system 10 goesforward to step S325. Then, the transaction management system 10, aftertransmitting the input mistake notifying page data to the ordererterminal, waits for inputting again the information to the identityauthentication page.

If the orderer proves, though it can be confirmed that the user ID, etc.is valid (step S327; YES), to have a nonpayment of fee and so on (stepS328; YES), the transaction management system 10 transmits animpossible-of-purchase notifying page data used for the browser todisplay the Web page as shown in FIG. 18 (step S329), and finishes theprocess for the accounting process request.

Whereas if the orderer does not have the nonpayment of fee and so on(step S328; NO), the transaction management system 10 reads theinformation on the respective added items in the input boxes added tothe identity authentication page from the customer DB 141 of the accountmanagement system 140, and judges whether or not all pieces ofinformation set in the input boxes on the identity authentication pageare correct (step S330). Then, if unable to confirm that the informationset by the orderer with respect to the added items is correct (stepS331; NO), the transaction management system 10 transmits the inputmistake notifying page data to the orderer terminal (step S325), andthereafter waits for inputting again the information to the identityauthentication page.

Whereas if it can be confirmed that the information inputted withrespect to the added items is correct (step S331; YES), the transactionmanagement system 10, as shown in FIG. 15, reads the purchase restraintcondition information containing the processing target user ID from thepurchase restraint condition DB 26, and judges based on the readoutpurchase restraint condition information and an article classificationand an article price of the processing target article (identified by theprocessing target article code) whether or not the processing targetarticle falls into a category of an article that should be restrainedfrom being purchased by the orderer (step S340). Note that the purchaserestraint condition information containing the processing target user IDdoes not exist in the database, the transaction management system 10judges that the processing target article is not the article that shouldbe restrained from being purchased.

If the processing target article falls into the category of the articlethat should be restrained from being purchased (step S341; YES), thetransaction management system 10 transmits to the orderer terminal thedata for having a Web page showing this purport displayed (step S350).Namely, the transaction management system 10 makes the orderer terminal(browser) display the Web page as shown in FIG. 19.

Whereas if the processing target article does not fall into the categoryof the article that should be restrained from being purchased (stepS341; NO), the transaction management system 10 creates data fordisplaying a account item name setting page by use of an articlestandard name of the processing target article, and sends the same datato the orderer terminal (step S342).

As schematically illustrated in FIG. 20, the article standard name(“MAGAZINE A”) of the processing target article is shown in the accountitem name setting page. The account item name setting page has an inputbox (provided on the right side of “CHANGED” for inputting a accountitem name and an “OK” button for transmitting the information containingthe account item name inputted to this input box.

When receiving the information transmitted by pressing the “OK” buttonon the account item name setting page (step S343; YES), the transactionmanagement system 10 transmits to the orderer terminal a piece of datafor displaying a final confirmation page (step S344). For example, if“MEDICAL MAGAZINE PERIODICAL SUBSCRIPTION FEE” is set as a account itemname on the account item name setting page shown in FIG. 20, thetransaction management system 10 makes the orderer terminal display, asshown in FIG. 21, a final confirmation Web page showing that a name suchas “MEDICAL MAGAZINE PERIODICAL SUBSCRIPTION FEE” will be used. Notethat if the orderer inputs nothing but presses the “OK” button on theaccount item name setting page shown in FIG. 20, the final confirmationpage showing “MAGAZINE A” in place of “MEDICAL MAGAZINE PERIODICALSUBSCRIPTION FEE”, is displayed on the display of the orderer terminal.

When detecting an event that a cancel button on the final confirmationpage is pressed (step S345; canceled), the transaction management system10 executes nothing particular and finishes the process for theaccounting process request.

While on the other hand, when getting the final confirmation, namely,when receiving the information implying that the confirmation button ispressed (step S345; confirmed), the transaction management system 10determines a transaction number given to a transaction with theconfirmation obtained, and adds pieces of accounting information on theprocessing target article to the accounting DB 27 for storing, as shownin FIG. 22, the accounting information consisting of a transactionnumber, a user ID, an article code, an article price, a customer code, aaccounted party code, an article supplier code, an article standard nameand an account item name (step S346).

Subsequently, the transaction management system 10 delivers an e-mailcontaining the contents of the processed executed, wherein an e-mailaddress registered in the ISP is used as a destination address (stepS347). Then, the transaction management system 10 transmits anaccounting process complete notification containing the transactionnumber, the article code, the price and the orderer IP address, whereina return destination address in the article target managementinformation serves as a destination address (step S348). That is, thetransaction management system 10 transmits the accounting processcomplete notification to the article supplier server 120 identified bythe return destination address in the processing target contractinformation, and comes to an end of the processing.

The article supplier server 120 receiving this accounting processcomplete notification, with the orderer IP address contained in thisnotification being used as a destination address, transmits data fordisplaying a Web page showing that the procedure is ended. Further, thetransaction management system 10 stores the transaction number, thearticle code and the price in the database for managing an articledealing condition, which is provided in the system 10 itself, andmanages a procedure of delivering the actual article and also a receiptof money by use of the information in this database.

Moreover, the transaction management system 10 periodically executes aprocess of notifying the account management system 140, identified bythe accounted party code, of the accounting information (not yetnotified) containing the same accounted party code that is stored in theaccounting DB 27.

Then, each account management system 140 executes the process as by thesteps shown in FIG. 23 when creating a bill give to each customer.

At first, it is judged whether or not the notification of the accountinginformation on the processing target customer is received (step S401).Then, if the notification of the accounting information on theprocessing target customer is not received (step S401; NO), the accountmanagement system 140 creates a bill for claiming only a fee charged forthe self-provided service (step S403). Whereas if the notification ofthe accounting information on the processing target customer isreceived, the account management system 140 creates a bill for claiminga fee for the self-provided service and a price of the article relatedto the accounting information on the processing target customer (stepS402). On this occasion, the account management system 140 uses theaccount item name contained in the accounting information as a name ofthis article. To be specific, the account management system 140 createsa bill 40 as shown in FIG. 24 with respect to a customer identified by acustomer code X6568762 contained in the accounting information stored inthe accounting DB 27 shown in FIG. 22.

Thereafter, the thus created bill is mailed, and the carrier collectsthe fee from the respective customers. Then, necessary settlements areconducted between each carrier and the settler and between the settlerand each article supplier. Namely, each carrier pays the settler a feeequivalent to the price of the article (which is an amount of money witha commission subtracted) out of the fee collected from the customer. Thesettler subtracts the commission and shares a profit corresponding to anamount of money gained for sales to each article supplier.

As discussed above in depth, according to the present online shoppingsystem, the purchaser of the article can buy the article withoutinputting a credit card number and can therefore enjoy shopping on theInternet without any anxiety for an adverse use of the credit cardnumber. Further, the purchaser is able to pay batchwise all the pricesof the variety of articles purchased from the plurality of articlesuppliers, and does not therefore feel troublesome with no necessity ofpaying to the individual providers. Moreover, the article supplier isreleased from the time-consuming operations of authenticating thecustomer identity and collecting the fees, and the carrier may emphasizethe advantage that the fee for the Internet shopping can be simply paid,with the result that the number of customers increases.

Furthermore, even when buying the articles from the multiplicity ofarticle suppliers, not each of the article suppliers but only thetransaction management system 10 is notified of the user ID, thepassword, the customer code etc. that must be inputted for conductingthe shopping, and hence these unique pieces of information do not spreadunnecessarily. Further, when the dealing is carried out, an e-mail isdelivered to the e-mail address registered in the ISP, and it thereforefollows that the authentic owner of the user ID can immediately discoverthat an illegal purchase takes place.

Moreover, the restraint condition setting password is delivered to theparty establishing the contract with the carrier, so that, for instance,a juvenile will buy an article on the Internet in such a form that theparent restricts the categories of the articles he or she is allowed toget.

Note that the transaction management system 10 in the embodimentsdiscussed above may be modified in a variety of forms. For example, thetransaction management system 10, though it receives the accountingprocess request from the article supplier server 120, may receive arequest corresponding to the accounting process request from thecomputer terminal 110 (the article supplier server 120 may provide thecomputer terminal 110 with a Web page including a button through whichthe above request is to be transmitted).

1. A transaction management system comprising: an authentication partfor performing authentication by sending a user identifier and apassword to an authentication system operated by an Internet serviceprovider that should authenticate an accounting target user; and arequest part for making an accounting request to an accountingprocessing system operated by other than said Internet service providerwhen said authentication part succeeds in the authentication.
 2. Atransaction management system for requesting a plurality of accountingprocess systems to execute accounting processes of fees, comprising: apart for receiving a process request for an accounting request from acustomer as a payer of fee; an acquisition part for acquiringidentifying information of said accounting process system that isutilized by the fee payer on the basis of the process request received,and necessary items of information for authentication; and a part forrequesting said accounting process system concerned to execute theaccounting process of the fee on the basis of the information acquiredby said acquisition part.
 3. A program executed by a computer,comprising: an authenticating step of performing authentication bysending a user identifier and a password in an authentication system tosaid authentication system operated by an Internet service provider thatshould authenticate an accounting target user; and a requesting step ofmaking an accounting request to an accounting processing system operatedby other than said Internet service provider when the authenticationgets successful in said authenticating step.
 4. A program executed by acomputer to function as a system for requesting a plurality ofaccounting process systems to execute accounting processes of fees, saidsystem comprising: a part for receiving a process request for anaccounting request from a customer as a payer of fee; an acquisitionpart for acquiring identifying information of said accounting processsystem that is utilized by the fee payer on the basis of the processrequest received, and necessary items of information for authentication;and a part for requesting said accounting process system concerned toexecute the accounting process of the fee on the basis of theinformation acquired by said acquisition part.